home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group98c.txt
/
000027_icon-group-sender _Tue Sep 15 09:00:17 1998.msg
< prev
next >
Wrap
Internet Message Format
|
2000-09-20
|
3KB
Return-Path: <icon-group-sender>
Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id JAA00801
for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Tue, 15 Sep 1998 09:00:17 -0700 (MST)
Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
id AA03129; Tue, 15 Sep 1998 08:59:49 -0700
Date: Mon, 14 Sep 1998 21:52:44 -0400 (EDT)
From: cwills@bix.com
Subject: RE: Context Switching
To: icon-group@optima.CS.Arizona.EDU
Message-Id: <9809142152.memo.74091@BIX.com>
X-Cosy-To: icon-group@optima.CS.Arizona.EDU
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO
Yes.. it really does require a seperate "thread" of execution. The
coswitch routine (the assembler code used for doing the context switch)
replaces the C stack frame with a different stack frame then re-invokes
the interepreter code. Note that this is not a "whole seperate executable"
but preserving the current dynamic set of variables while the co-routine
is running.
Also note that if you dig deep enough into co-processes (co-routines and
co-expressions) you will find that this is what is really going on under
the covers.
The algorithm used by Icon expressed in a C-ish pseudeo code is:
coswitch( old_cs, new_cs, first )
int *old_cs, *new_cs, first;
{
/* save SP, frame pointers, and other registers in old_cs */
if ( first == 0 )
{
/* load sp from new_sp[0] and clear frame pointers */
interp( 0, 0 );
syserr( "interp() returned in coswitch" );
}
else
{
/* load sp, frame pointers and other registers from new_cs */
}
}
---------
To implement the coswitch function using threads, one would have
to locate where coswitch is called, change the allocation of the
co-expression stack to a creation of a thread that immediately blocks
on a semaphore defined in the co-expression block.
Coswitch then would be passed the current co-expression's semaphore
and the co-expression's semaphore to swap to, "post" the called semaphore
and wait on the calling semaphore (if any of that makes sense).
Taking this alittle further, one might want to have a "master" thread
(the original thread created by the system) and then when &main is created
create a new thread for &main. This would allow &main to be "destroyed"
and still have the "master" thread always there. The master thread could
be used as a syncronizer if for some reason the OS needed stuff created
by a parent thread. If done correctly, co-expressions could actually
be executed in parallel (have the master thread perform all memory
allocations, GC, file, etc).
Cheyenne